4 



A Journal For FileMaker™ Users 


The 

FileMaker 

Report 


Reorganizing a Subscription Database -“What is a File?'' 


By Joe Kroeger 

When designing a new FileMaker solution to a 
database problem, there are several very basic ques¬ 
tions that need answering. The answers to these funda¬ 
mental issues then form a platform for building the 
detailed solution. The basic essential questions usually 
go like this: 

• What is the problem to be solved? (And how will we 
know when a solution has been devised?) 

• Given the problem, what is a file? 

• In each file, what is a record? 

• In each record, what fields are needed? 

There are additional supporting decisions - about 
reports, scripts, formatting, and equations, for exam¬ 
ple - but answers to the four fundamental questions 
above will at least have created a database that can act 
as a working foundation and can accept entry of data. 

There is no escaping these basic questions: they are 
always answered. We have no choice about making 
these four decisions, but we do get to choose whether 
or not to make the questions explicit and the answers 
conscious. (The advantage of being conscious is that 


we are more likely to know what we are talking about 
and more likely to generate answers appropriate for 
our tasks.) 

Note that there is no way to avoid the basic deci¬ 
sions yet still arrive at a solution; the only choice is 
whether the answers are implicit and vaguely arrived at 
or are explicit and consciously decided. We may not 
always be aware of our decision-making - nonetheless 
decisions are made, even if the answers seem to spring 
automatically into place. A process of database osmosis 
may be at work, or your mind may be relying on past 
experiences, or you may be using answers you picked 
up from someone else, or you maybe making quick 
extensions of ideas you used in the past - so quick that 
you don’t even recognize the decision process. Even if 
you just buy a template, you are deciding that it will 
answer the basic issues listed above. 

Please note that the four basic questions are almost 
always answered iteratively - that is, an answer to one 
will influence answers to others, even those that may 
have preceded it. Thus you will find yourself revisiting 
earlier decisions in the light of later design activity. 

One of the nice advantages of FileMaker is that changes 
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can often be made without 
disturbing already-entered 
information, so data-entry 
can often proceed quite early 
in the design process. This 
makes iterative design work 
much easier, allowing the ex¬ 
perience of entering data to 
improve the design. 

While all the basic ques¬ 
tions are valuable and all 
must be answered, one way 
or another, some will be 
more important than others 
in different design situations. 
A lookup table will naturally 
require emphasis on different 
design aspects than an in¬ 
voicing system. 

I often am concerned 
about what a record defines, 
usually with productive re¬ 
sults - see box on the next 
page - but I recently had to 

Figure 1 spend a good bit of time 

thinking about what is often an even more 
fundamental question; What is a file? The 
definition of a file can sometimes influence 
record definitions and that relationship 
also works in reverse. 

Initial Subscription Design 

To keep track of subscribers to The File¬ 
Maker Report, several years ago 1 designed 
the file setup shown in Figure 1. Note that, 
logically enough. Subscribers names and 
addresses were kept in a separate file from 
Prospects. The Prospects file contained a 
lot of information about mailing history 
and the source and evolution of the ad¬ 
dress. In the Subscribers file, of course, we 
kept information about the current sub¬ 
scription status and the latest payments. A 
simple lookup link allowed entry of a new 



subscriber using address information from 
the Prospects file without having to re-en¬ 
ter it. And Subscribers also contained a 
large number of calculations that allowed 
reporting on the number of subscribers 
and amount of revenue per issue. 

(When we began selling FileMaker tem¬ 
plates, more files were added to the set. See 
Figure 2. It was easy to make a clone at the 
start of a new year and keep the old files as 
order archives.) 

This straightforward answer to What is 
a File? worked well for several years. There 
were modest changes made as evolutionary 
transitions from FileMaker Plus to File¬ 
Maker II to FileMaker Pro. A few new 
fields were introduced. But over time a few 
problems gradually cropped up with this 
original design: 

(a) The Prospects file began bumping 
into the FileMaker file size limit as more 
and more names were added. Even rela¬ 
tively frequent file compressions provided 
only temporary relief. This file size limit 
was 16 MBytes or 32,000 records in the old 
days and grew to 32 MBytes with no record 
count limit, where it remains today. Fortu¬ 
nately for us, but unfortunately for the 
Prospects file, the number of prospects ex¬ 
panded faster than the FileMaker file-size 
limit grew. 

(b) A lot of time and effort was being 
expended maintaining a double set of 
records for each subscriber - one in the 
Prospects file and one in Subscribers. Ad¬ 
dress changes had to be entered in one file 
and then looked up into the other, or else 
entered manually in both. It would have 
been possible to save both space and dou¬ 
ble editing by deleting subscriber records 
from the prospects file, but this would have 
meant deleting the mailing and address- 

(continued on page 4) 
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"What is a Record?" 

This question is often high on the list of critical issues when designing a database. While the question has 
been worded in a variety of forms for a long time, we are all indebted to Mike Harris for this succinct for¬ 
mulation. It is a phrase that is often handy when devising answers to new problems and when helping to 
understand the structure of an existing file. For many users who are trying to resolve a design problem and 
who have defined a record only implicitly, simply asking the question out loud can be quite illuminating 
and may quickly light the way to a solution. Or at least point out a conflict or a difficulty. 

What is a Record? translates to What type of entity or action or attribute is described by one record such that 
when a new entity is introduced, a new record is required? One record might be one ZIP code or one order or 
one book or one employee or one bank check or one set of grades or one field of cotton or one tree or one 
ancestor or one day or one address ... and so forth. 

Some such definitions are easy to make: a U.S. ZIP/City/State lookup table, for example, is ZIP oriented 
(ZIP is the lookup key). Each ZIP code needs a new record and each record needs to contain associated city 
and state information about each ZIP. Thus each record contains (at least) three fields: ZIP, City, State. 

For an order-entry file, one record = one order (at least usually) and that is simple enough. If we then 
follow the logic that all information about one order should reside in one record, it leads us into more de¬ 
sign decisions: what is to be looked up for each record (customer address, product descriptions, prices, tax 
rate, shipping charge, and so forth), and what is to be calculated about each order (product subtotal, tax 
amount, order total and so forth). 

If you make it a habit to ask What is a Record? about all your files, you will be amply rewarded. 
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change histories as well. And it would also 
have meant transferring expired subscrib¬ 
ers back to the Prospects file for future 
mailings. Messy. 

(c) As the functionality of the Subscrib¬ 
ers file evolved, it became desirable to add 
additional status information for each Sub¬ 
scriber in order to keep track of all pay¬ 
ments and all starting and ending subscrip¬ 
tion and renewal issue numbers rather 
than just the most recent status. 

(d) The Subscribers database was get¬ 
ting bigger and bigger since it held the total 
history of all past and present subscribers, 
including those who had expired. With the 
many calculations included in Subscribers, 
the file was getting creaky and slow. 

(e) These problems were aggravated be¬ 
cause, for a variety of reasons, we keep 
most bad addresses along with the good 
ones. While we could have created a new 
file to contain the bad addresses only, that 
would have made it more difficult to check 
bad ones against incoming addresses. 


Figure 3 





Changing the Structure 

New design requirements often arise 
out of such evolving sets of problems. 
There is a natural tendency to stick with a 
working system, even putting up with 
some inefficiency, until forced to redo the 
whole scheme. At some point, though, it 
often becomes necessary to go back and 
ask the four basic design questions. 

The Problem (Basic Question #1)1 was 
faced with was to devise a new structure 
that would allow us to track mailing and 
address-change information for prospects, 
adding detailed subscription information 
for subscribers, while solving problems (a) 
through (d) above. 

Answering What is a File? turned out to 
be tougher than I thought it would be and 
the file structure ideas I considered 
changed through several variations. My 
initial thoughts went in the direction of 
Figure 3 - indeed, I did some design work 
in this direction. I anticipated using the 
same general archive scheme as for tem¬ 
plate orders, but adapted for subscribers. 
(The template ordering files have been 
omitted from Figure 3 for clarity.) 

I wanted to keep the basic setup as be¬ 
fore, but be able to separate from the Sub¬ 
scribers database the records of expired 
subscribers and archive them in separate 
files. There would then be a new database 
for each calendar year, carrying over each 
January the still-active subscribers. That 
would minimize file size and speed up sub¬ 
scriber calculations within each file. But it 
would also have meant that an overview of 
all the historical values would mean calcu¬ 
lating several files. 

(A variation of Figure 3 is to just keep 
all past subscriber history records in one 
file and at the end of each year move all 
expired subscriptions from Active Sub¬ 
scribers into just one Inactive Subscribers 
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file. This also would make it easier to per¬ 
form the calculations when needed.) 

I devised the general approach in Figure 
3 before the Prospects file started getting 
too large. In an attempt to keep going in 
this direction in spite of file size growth, I 
considered splitting Prospects by ZIP code 
into multiple files. See Figure 4. This makes 
each Prospects file smaller and allows the 
accumulation of just about as many pros¬ 
pect records as desired through continued 
file subdivision. 

But note that the lookup path into the 
Subscribers file is broken for all of the 
Prospects files (except perhaps one). In my 
(excessively) optimistic moments I thought 
that it would not be too bad to import the 
desired record from one of the Prospects 
files into the Active Subscriber file for each 
new subscriber. It worked fine... not! 

One unanswered question: for new sub¬ 
scribers not already in a Prospects file, 
would we add a record to both Prospects 
and Subscribers? I never had to decide. 

One major design issue for this ap¬ 
proach was to account for the start-of-year 
and end-of-year outstanding subscription 
liability and issues owed for each active 
subscriber in order to be able to report on 
the financial status of the journal. Several 
special fields and calculations would be 
needed - for both the Active and Inactive 
subscription files - that would derive those 
values based on the number of issues deliv¬ 
ered, any renewal dollar amounts entered, 
and so forth. 

In the old original scheme in Figures 1 
and 2 (and the proposed ones in Figures 3 
and 4 as well), there are a large number of 
calculations and summaries required to 
derive basic management information. It 
thus takes a lot of work to calculate (a) 
how many subscribers and (b) how much 
revenue there was for each issue, in a file 


that is organized as one record = one sub¬ 
scriber. These calculations consume a lot of 
space in the file and take a very long time 
to calculate, even on a fast machine. 

Nonetheless, in spite of all these diffi¬ 
culties, I bullheadedly continued to plan 
the implementation of this approach. I was 
working away at defining fields and equa¬ 
tions (Basic Question #4) without being 
fully conscious of Questions 2 and 3. 

But eventually it occurred to me to re¬ 
examined the basic nature of the prob- 
lem(s) I was trying to solve. It would have 
been better if I had been maintaining a 
consistent policy of regular re-evaluation 
of my premises while designing. Now I do. 

Figure 4 
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Figure 5 



I realized that Figures 2 and 3 were in¬ 
complete and they only addressed some of 
the issues that were brought up by Basic 
Question #1. It appeared that not all the 
desired characteristics could be achieved - 
some design compromises would be need¬ 
ed. I needed to rethink the problem itself, 
set some priorities and entertain some rad¬ 
ical alternate approaches. 

I eventually arrived at the struc¬ 
ture in Figure 5. To do so I had to 
question seriously some of the work 
I had already done and let go of 
much of the momentum I had ac¬ 
cumulated while moving down the 
wrong path. When I pulled away 
from a focus on fields and records, I 
realized that while the problem def¬ 
inition had not evolved much in my 
“I mind, the architecture of the solu¬ 
tion I had been working on was not 


the only possible approach. I had been re¬ 
structuring only a portion of the existing 
design when I actually needed to reevaluate 
the fundamental definition of What is a 
file? 

After more mental manipulation, and 
following a particularly intense session at a 
blackboard trying to verbalize the require¬ 
ments and assumptions, I arrived at a 
strange idea: I might be able to combine the 
subscriber records and the prospect 
records into a single type of file. That is, a 
file for one group of ZIP codes would con¬ 
tain records for prospects, bad addresses, 
active subscribers, expired subscribers, and 
template customers. Strange. 

At first this seemed silly - there would 
have to be quite a few fields that were 
needed only for subscribers and others 
needed only for prospects. 

Still, if the inefficiencies would not be 


Calculations and Reports 

The problem of the large number of calculations remained to be solved. If 
the master prospect/subscriber files were already crowded with an abundance 
of data and support fields, it occurred to me that a separate file just for the 
calculations might work well. (This file is included in Figure 5.) While there is 
a modest disadvantage to a separate calculation-and-report file (the need to 
import data into the calculator), the advantages, in the context of the com¬ 
bined prospects/subscribers design, are overwhelming. 

The procedure to use the Calculation file is (a) Find all subscribers in all 
prospects/subscribers files, (b) Import all subscriber records into an empty 
Calculation file, (c) trigger the summary calculations and go to lunch, (d) 
print the reports, (e) make a clone for use the next time (and throw away the 
full calculation file if you want to save disk space). 

Quarterly reports are usually sufficient, so, fortunately, the calculation ac¬ 
tivity is not needed very often. Note that only a few fields need to be imported 
to generate the reports. Even some information that couldhe summarized in 
the prospects/subscribers files is reserved for the Calculation file instead in 
order to keep the prospects/subscribers files as slim as possible. 

Separating calculations from data is a powerful technique in many circum¬ 
stances. Take advantage of it. 
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too severe, several difficulties would be ad¬ 
dressed. (1) Note that only one record is 
maintained for each person, no matter 
what their status. And all the status and 
tracking information for that person is 
complete in a single record (except for any 
bad addresses that maybe retained). (2) 
Lookups or transfers into a separate sub¬ 
scriber file are no longer required. (3) As 
files get too large, they can be split easily 
into smaller groups with little difficulty. 

After more exploration and a couple of 
trial file designs (trying to poke holes in the 
concept), I decided that this strange file 


definition would work well for us. I com¬ 
mitted to a full-scale implementation. 

For me the lesson to be learned is that 
entertaining wild or off-beat ideas can be a 
productive way to find good solutions. 

And being conscious of the four Basic 
Questions helps too. It would have made 
the transition to the new design easier had 
I made the changes earlier. On the other 
hand, would I have been able to evolve this 
design earlier? Unknown. 

Executing the Design 

Once the file structure was in place, the 
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Note 


Entering Library 
orders remain a 
modest problem. 
Somehow it needs to 
be easier to transfer 
existing addresses 
into the order file. I 
am experimenting 
with creation of a 
single supporting 
lookup file that 
includes addresses 
only of likely as well 
as past customers. 


fields had to be defined. This was an im¬ 
portant part of the process since I was try¬ 
ing to interleave several types of informa¬ 
tion within each record. The fields can be 
divided into five groups: 

• Name and address fields 

• Address status fields 

• Mailing history fields 

• Subscription status and history fields 

• Support and debugging fields. 

Altogether, there are 73 fields including 
26 calculations in each prospects/subscrib¬ 
ers file. Figure 6 shows one of the layouts. 
Other layouts are used for printing labels 
and invoices. 

I created a couple of alternate address 
layouts with subsets of the fields shown in 
Figure 6 on the assumption that the screen 
would re-draw faster and it would be easier 
to do some types of editing on smaller lay¬ 
outs. But it has turned out that we almost 
always use the superset layout in Figure 6 
now that we are working on a full-page 
display. At least for me, more information 
on the screen seems better. 

Repeating fields, as you can see from 
Figure 6, came in handy for the mailing 
history, address status, and subscription 
history information. Several of the support 
fields are used to track the repeating fields 
and allow their manipulation. 

I put the design elements together into 
one file, tested and debugged it, then made 
clones for the other ZIP groups. Since a 
few self-lookups were used, each clone re¬ 
quired customization to adjust for each file 
name. 

The next hurdle was transferring infor¬ 
mation from old files into the new ones. 
The original Prospects and Subscribers 
files had their field names adjusted to 
match the new design. Prospect records 
were imported with little difficulty since 
not much had changed. But the informa¬ 


tion about subscribers was expanding and 
it was necessary to go through each trans¬ 
ferred subscriber record to make sure it 
came across properly, to adjust it manually 
to the new format if necessary, and to ex¬ 
tract subscription renewal history that was 
buried in the old records. We transferred 
and edited the active subscribers first, and 
then worked on the inactive subscribers as 
a background task. A couple of temporary 
fields were added to the new design to aid 
this process. 

Once all the records were in the new 
files, the work really piled up. It was neces¬ 
sary to add record-serial numbers and set 
up line-serial numbers for the sets of re¬ 
peating fields. In addition, there was now a 
prospect record for every subscriber record 
and each of the two held different types of 
information. It meant (a) identifying each 
record pair, (b) transferring all the relevant 
information from the old prospect record 
into the upgraded subscriber record, and 
(c) marking the processed prospect records 
for deletion. This has been a giant effort 
that is still, months later, not complete. 
(And the Calculations file remains not 
quite complete as well.) 

Has the new design introduced new 
problems? The answer is “yes” but they are 
(so far!) modest and manageable. 

Overall, these basic structural changes 
have accomplished the goals and solved 
most of the problems; the change has been 
good. And I learned a lot about the Basic 
Questions. 
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Selective Relookups For New Fields 


By Janet Tokerud 

After building a database that in¬ 
cludes lookups from other files, you may 
later want to add another lookup field, 
usually to add additional levels of automa¬ 
tion. When I implement a new lookup, it is 
often based on the same trigger field or key 
field as other existing lookups in the file. 

Let’s say we have a Clients file and an 
Invoices file. The invoice contains lookup 
fields that bring in the client address, 
phone and hourly billing rates. Let’s say 
that there are now 200 invoices in the In¬ 
voices file and I want to add a lookup for 
the fax number for each client. 

Normally, I would base the lookup on 
the unique identifier for the client file - 
something like a Client Number or Client 
Code. If 1 set up the new fax number look¬ 
up to trigger based on the Client Code, 
when I choose Relookup in the Invoices 
file to update old records with the client’s 
fax number, all the other lookups based on 
the Client Code will also be relooked up. 
That means all the addresses, phones and 
hourly rates will lookup again. I may not 
want that to happen because I want to re¬ 
tain, for example, the hourly rate that ap¬ 
plied when the invoice was originally created. 

The point is that I would like to trigger 
a lookup for only the fax number and not 
look up every field that has a lookup based 
on Client Code. Here are 2 work-arounds: 

Approach #1. 

1. Create a new calculated field in the 
Invoices file called Temp Client Code 
whose equation is “= client code”. After 
the Temp Client Code has calculated, 
change its field type to text. 

2. Create a new fax number text field in 


the Invoices file. 

3. Create a lookup for the fax number 
based on a match between Temp Client 
Code in the Invoices file and Client Code 
in the Clients file. 

4. In Browse mode click in the Temp 
Client Code field and choose Relookup. 
This will trigger a relookup of just the fax 
number and will leave alone all other look¬ 
ups based on Client Code. 

5. Now go back and change the lookup 
definition for the fax number field so it is 
keyed on the Client Code field. This will 
allow the fax number to look up automati¬ 
cally when the client code is entered into 
new invoice records as they are created. 

6. Delete the Temp Client Code field. 

That’s all there is to it. There is some 

extra work involved here, but often it is less 
than trying to reverse unwanted lookups. 

Approach #2. 

1. Create a new fax number text field in 
the Invoices file. 

2. Using entry options, set a lookup for 
fax number from the Clients file using the 
Client Code in both files. 

3. In the Entry Options dialog of the 
other Invoices lookup fields triggered by 
the Client Code field, un-check the check¬ 
box for the lookup. 

4. In Browse, click in the Client Code 
field and choose the Relookup command. 

5. When the Relookup is complete, go 
back to Define Fields and reactivate the 
lookup for those lookup fields keyed by 
Client Code. (Thus undoing step 3.) 

Pick an approach based on which is the 
least amount of work. If there are only a 
couple of other lookups in the file, #2 will 
be easier. If there are several, #1 will proba¬ 
bly be easier. 
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Tracking Project Contacts: Who Said What 
to Whom and When? 


By Mike McLane 


Note 


Numbers in brackets 
in the text, like (22- 
23], refer to sections 
of the FileMaker Pro 
User's guide if you 
would like to 
implement your own 
version of this file. 


This article describes what I consider 
to be an “elegant” solution. You know, one 
of those things that makes you say, “Why 
didn’t I think of that?” Like wondering 
why you didn’t invent the paper clip. 

As a program manager, I track several 
different projects and coordinate the ef¬ 
forts of many people in completing tasks. I 
was looking for a way to organize such 
contacts and the activities involved in sev¬ 
eral different projects. I needed the ability 
to recall the chronology of activities, usual¬ 
ly as they related to each project. FileMaker 
Pro to the rescue! 

The basic structure of the resulting 
template is anything but complex. Each 
contact (phone call, face-to-face meeting, 
letter, etc.) is a new record. The basic data 
elements in each record are: 


1. Time and date of the contact. 

2. Name of the related project. 

3. The person in my office who participat¬ 
ed in the contact. 

4. A narrative of the contact, including the 
name of the person contacted. 

5. A future date at which action is expect¬ 
ed, as set forth in the narrative. 

6. The date when the action was complete. 

Figure 1 shows the data entry screen. I 
use FileMaker features to speed data entry 
and promote uniformity. Each record, 
when created, automatically receives a date 
and time stamp [p 2-13). To insure data 
integrity, I made these fields “Prohibit 
modification of auto-entered values” 

[p 2-13]. The Project Title field contains 
the project names you wish to track. These 
are in a value list [p 2-16]. (You should 
change the generic titles shown to some¬ 
thing more descriptive.) I prefer to display 
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this list as check boxes 
[p 3-33] because this lets me 
quickly (and uniformly) 
assign the contact to a spe¬ 
cific category. If several 
projects are discussed, the 
record can be marked to 
show each project. In that 
way, future reports of any 
checked project will include 
this record. 

The narrative (in the 
“Evenf field) is free-form 
text containing notes cover¬ 


Created 
Person Here 
Action Due 

Time 

Complete 

Event 

Project 1 



2 Nov, 91 

Mary 

7 

10:18/^ 

Bob Jones calied to say that the entire powersupplyforthis system ■ 
avaiiabie untiiJune 92 

3 Nov, 91 

Mike 

11;30/iM 

icaiied Bob Jones to ask him if he had checked aiisuppiiers in botht 
and Canada. He said he had but wouid check outMeTicoas he has P 

10Nov,91 

10Nov,91 

Siemens maybe producing there. Bob viil be back to me in a week o 
the other 

10Nov,91 

Mike 

7 

11:30/iM 

Bob Jones calied and said no iuck with the Meccan connection. Siei 
not started up, yet. The foiiowing sentences are included just to fill o 
field and to demonstrate the ability of the reporting system to slide tP 
both up and down as necessary to out all the event narrative on the | 
whenitmayoverflowtheboxinwhichitisenteredontheDataEntry 


ing the contact to whatever 

level of detail you consider proper. Figure hand. This leads to the “tickler” section on Figure 2 

2 shows a report containing some exam- the data entry layout. 

pies of narratives. Once it is determined that a record 

The above fields were the only ones in needs a tickler, I click on the Yes button 
my first incarnation of this template. As I near the Action Required? label. The 

used it, I found it handy to add several oth- record automatically receives an additional 

er features. Thanks to the ability of File- date stamp. This tickler date defaults to a 
Maker to accept added fields, none of my date 14 days in the future. The user then 

early work was lost as I improved the tern- has the option of changing the action due 

plate. date by entering a positive number to make 

When I started to run the template in a it later or a negative one to make it earlier, 

multi-user mode (so others could make This somewhat convoluted method is used 

entries when I wasn’t available), it became to make sure that every record which is 
apparent that I needed to be able to identi- tagged as needing a reminder date has some 
fy persons other than myself who recorded date automatically assigned. The operator 

contacts in the template. Because of this, I then changes the default date as necessary, 

added the Person Here field. This field Limiting the allowed values of the change 

uses a value list of people’s names [p 2-16). number in the entry options dialog box 

It defaults to my name, because I make [p 2-14] insures that the operator cannot 

major use of the template. I format the assign a tickler date prior to the date of 

field as a pop-up list [p 3-33] to save space record creation, 
on the layout. 

Lastly, I found myself wanting to make Using the Template 
a tickler to remind me to take an action (or Each morning I open the template and 
expect one) on a future date. While there Find all records with Action Due Date 
are many programs that can do this {Smart times equal-to-or-less-than today and with 
Alorms, for example) I saw no need to an empty Action Completed field. (You 

open another program or DA to make the could make an Action Due Now script to 

entry when I already had FileMaker at automate this, if desired.) I then review or 
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Date Action Complete 
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print all records found (using the Print 
SELECTED or View SELECTED scripts) 
and my daily tickler action list is complete. 

In another example, it may become 
necessary to document each contact made 
concerning a chosen project. Nothing 
could be easier! Using the data entry 
screen, the operator Finds all records for 
that project and then executes the Print 
SELECTED script and sits back. The chro¬ 
nological report documents everything. 

Instead of automating reports, I prefer 
to maintain maximum flexibility and exe¬ 
cute manual Find requests meeting my 
search criteria and then print the resulting 
report to either the screen or to paper, as 
conditions warrant. The Print SELECTED 
and View SELECTED scripts sort the found 
records into chronological order, group by 
projects if more than one 
project is in the found set, and 
then present the records on 
either the screen or on paper. 

Because FileMaker indexes 
each word in the narrative 
field you can do interesting 
searches of the entire database. 
This provides unexpectedly 
powerful capabilities. You 


could, for example, find all instances in 
which you had recommended a particular 
subcontractor or product. Another use 
might be to examine all the Event fields by 
searching for a particular name. You can 
then find all contacts with that person, 
without regard to particular projects. They 
are then presented in chronological order. 

Error Traps 

I included several logic error traps that 
display screen messages. For example, if a 
record has the No button checked under 
Action Required (the default value) and the 
operator enters a date-finished date, the 
record notes this is a logic error. Figure 3 
shows the presence of the error. The calcu¬ 
lation to implement this flag is: 

Alert2 = {text result} 

If (ActionDue = "No" and 
ActionComplete > 1/1/19, 

"«-Logic Error","") 

Removal of the ActionComplete date 
or checking the Yes button will remove the 
error message. Another action causing an 
on-screen error message is the assignment 
of an action completion date which is earli¬ 
er than the record creation date. Correc¬ 
tion of the completion date fixes this prob¬ 
lem. There is one final error trap. If the 
operator enters a number to change the 
action due date on a record which has the 
No button checked under Action Required, 
the error is pointed out. 

This template is a relatively straight¬ 
forward design, yet is very productive. File¬ 
Maker strikes again! , 
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FileMaker Quick Tips & Techniques 


Network Mail Merge 

One limitation with FileMaker is that it 
cannot export or import records over a 
network. This is often a very good thing 
because it would likely take forever. Even 
exporting to a text file - normally a quite 
quick operation - could be slow across a 
network, at least for anything beyond a 
tiny file. 

There is (at least) one situation where it 
would, nonetheless, be nice to be able to 
export across the network to a text file: 
mail-merge with a word processor. Net¬ 
worked mail-merge may be unusual but it 
can be quite productive. There are a couple 
of work-arounds that might provide viable 
solutions. 

• Instead of merging address data from 
FileMaker into text in a word processor, try 
doing the text right in FileMaker. No ex¬ 
port is needed and remote users can access 
any or all files for printing across the net¬ 
work. 

• If you do need to merge data with a 
word processor, export the text locally and 
transfer the text file itself across the net¬ 
work to the destination machine where a 
normal merge operation can be performed. 

• While network exports don’t work, 
lookups certainly do. Depending on the 
volume of addresses to be processed, it 
could be reasonable to look them up over 
the network. 

Help Screen Buttons 

(From reader Rod McDonald in Australia) 

“More and more people entering infor¬ 
mation into databases are not especially 
trained and may not have time to learn the 
ins and outs of FileMaker. In some of my 
databases I have used FileMaker Pro but¬ 


tons to access on-line help information 
about individual fields. Underneath each 
field name on a layout I created an invisi¬ 
ble button that calls up an associated lay¬ 
out. Each of these field-description layouts 
contains no fields but merely layout text 
which explains what information is needed 
in the field, the format to be used, and so 
on. A line at the top of the data-entry 
screen alerts users about how to obtain extra 
information. This approach has eliminated 
the need for printed instruction sheets.” 

There are lots of ways to make use of 
this nice tip from Mr. McDonald. It is es¬ 
pecially handy on a busy layout where visi¬ 
ble help buttons would only add to the 
clutter. If there is a title on the data-entry 
layout, it too can be a button that accesses 
more information. Any layout text can be¬ 
come a button directly, which will often be 
easier than making an invisible button be¬ 
hind the text. 

If you are using one data-entry layout, 
returning to it from the information screen 
is easy enough: each information screen 
can have a button at the bottom that sim¬ 
ply switches to the data-entry layout. But if 
you have two or three data-entry layouts, it 
is more difficult for the information screen 
to know how the user got there. One an¬ 
swer is to make a copy of each help layout 
for each possible return destination, and 
customize the return button for each one. 

Slide Right 

(by Mike Harris) 

“The FileMaker Pro Slide options allow 
us to slide fields left and/or up with consid¬ 
erable flexibility. But what about sliding 
right? I recently had a situation where I 
wanted to slide the pound sign (#), used as 


By Joe Kroeger 


Be Aware 


When FileMaker 
Recovers a file it does 
not preserve any 
rearrangements you 
may have made to the 
ordering of scripts or 
field definitions. (It 
would be nice if it 
would at least 
attempt to do so.) 
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Note 


In printed equations 
this journal uses ^ to 
designate where a 
space should be in 
the real equation. 


a label object to abbreviate for “number”, 
to within one space of an invoice number 
and I wanted the combination to slide as 
far right as possible, to align with the right- 
hand margin of my invoice layout. 

“Simple careful placement of the “#” 
label and the Invoice Number field worked 
as long as my invoice numbers all had the 
same number of digits. The Invoice Num¬ 
ber field can always be formatted as an 
align-right field (using Text Align in the 
Format menu, which applies to both num¬ 
ber and text fields) and the “#” placed on 
the layout exactly one space from where 
the left-most invoice number digit will pre¬ 
dictably appear. 

“However, I wanted a scheme which 
would work regardless of how many digits 
were in the Invoice Number field. The so¬ 
lution is to create a new field, a text calcu¬ 
lation, which always properly combines 
and spaces the “#” and the invoice number: 

Display Invoice Number = {text result} 
& Invoice Number 

“When an “align-right” Display 
Invoice Number is used on the layout in 
place of the “#” label and the Invoice 
Number field, you get the equivalent of a 
slide-right effect working on these two ob¬ 
jects. 

“Naturally, this “calculation format¬ 
ting” is handy for other situations where 
layout formatting is inconvenient or im¬ 
possible. It is particularly useful in the 
name and address part of form letters 
when address records may not be consis¬ 
tently entered in the database’s separate 
address fields (First Name, Last Name, 
Street, etc.). In some situations where slide 
up and slide left of the individual fields 
does not always produce perfect format¬ 
ting, it may be easier to text-calculate a 
good combined Name/Address field. 


“It will no doubt occur to many readers 
that, in the example of this single charac¬ 
ter, “#”, there is another, very simple solu¬ 
tion. The “#” could be easily auto-entered 
as part of the Invoice Number since File¬ 
Maker Pro allows alpha-numeric serial 
numbers (see The FileMaker Report, Issue 
36, page 6). If Invoice Number is defined 
as a numeric field, FileMaker ignores the 
pound sign for all practical purposes. Still, 
the calculated display field is a more gener¬ 
al solution for all field and object types.” 

Finding Non-date Data in a Date Field 

I had occasion recently to convert a text 
field into a date field. I had used the old 
text field to mark address records that had 
and had not been transferred to another 
database and it contained a few text codes. 
For example: “mt” (for “empt/’), meaning 
that the record had not been transferred, 
“xP for transferred, “ud” for updated, and 
a couple of others. 

The problem arose after changing the 
field type definition from text to date - the 
text codes were not recognized by File¬ 
Maker as valid dates. This makes sense 
since they were indeed not dates. I at¬ 
tempted to Find, for example, all the “mt” 
entries so I could change them to a date. 
Sorry, no can do, FileMaker only recogniz¬ 
es date-type information in a Find request. 
This means that there was no longer any 
way to discriminate between non-date-for¬ 
mat entries in the field. 

I suggest that you change any codes in 
such a field to the desired dates before 
changing the field type definition. If you 
can’t do so or if you have to deal with a 
field already changed, you might think 
about changing back to text, performing 
the appropriate replacement, then chang¬ 
ing to a date-type again. 

But if for some reason you need to 
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replace the text information while the field 
is a date-type, FileMaker provides a couple 
of aids. When the conversion is made from 
text to date, FileMaker brings up a warning 
that some non-date-formatted information 
is present and that it can be found using 
the value 00/00/0000 in a Find request. 

If you View Index (.. .er, Paste From 
Index) on the field in question, you’ll note 
that 00/00/0000 is the first entry as long as 
there is non-date data in the field. And 
you’ll notice that no non-date stuff appears 
in the index window. Using 00/00/0000 in 
a Find request will locate all records with 
non-date data. If you would like, you can 
Sort and then Omit sub-groups of records 
from the found set in order to end up with 
a set of just one code that you would like to 
replace. Repeat for any other codes. 

Instead of typing 00/00/0000 it will be 
easier, especially for repeated usage, to take 
advantage of a shortcut built into FileMak¬ 
er: use a question mark in the Find request. 
The question mark performs the same op¬ 
eration as 00/00/0000. (Note, by the way, 
that using the value 00/00/00 as the Find 
value does not work; FileMaker does not 
know what to make of it.) 

Tracking Transfers 

The reason for the change described in 
the previous Tip was to provide a better 
way to track address transfers. When an 
address has been modified or invalidated 
or has a more recent validation, I need to 
transfer it again. Instead of a binary indica¬ 
tion of transferred or not-transferred for 
each record, or a manually-entered indica¬ 
tion of a modification, I wanted each 
record to automatically provide an indica¬ 
tion of the transfer status. I ended up creat¬ 
ing three fields: 

LastValidDate 

LastT ransferDate 


ValidXTransferDelta 

LastValidDate is a calculation with a 
date result that looks at several pieces of 
data in the record, decides which is the 
most recent, and presents that date as a re¬ 
sult. It looks at the most-recent subscrip¬ 
tion date, the most recent address modifi¬ 
cation date, a good/bad indicator, and so 
forth. It uses several nested If functions to 
decide which date is later and which 
should dominate. 

LastTransferDate is a date field where I 
enter the date that the record was last 
transferred to the destination file. When I 
have found a set of records and imported 
them into the target file, it is easy to put 
the current date into the LastTransferDate 
field of the first record and then Replace it 
into all the records of the found set. This is 
the field that used to be a text field holding 
a few text codes. 

ValidXTransferDelta is a calculation 
that subtracts LastTransferDate from 
LastValidDate. The result is the number of 
days difference between the two dates. 

Thus those records that do not have a new 
LastValidDate value since the last transfer 
will have a negative count of days (because 
LastTransferDate will be later than 
LastValidDate) and I can ignore them. 
Those that have a modification after the 
last transfer will have a positive count of 
days, making it easy to locate those records 
after the editing is complete or when a 
scheduled transfer is ready. 

While it would be possible to convert 
the output of LastValidDate to a binary 
value, the actual count of days is useful for 
discriminating between records that have 
been transferred recently and those where 
it has been a long time between the last up¬ 
date and the last transfer. If that is not of 
interest, just look for any value greater 
than zero. ••-V* 
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Do you have a Quick 
Tip that you would 
like to share with 
other subscribers? 
Our authors earn 15<t 
per word. Any File¬ 
Maker topic you find 
interesting is fine. 
Drop us a note or 
give us a call. 
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